Method and devices for error tolerant data transmission, wherein retransmission of erroneous data is performed up to the point where the remaining number of errors is acceptable

ABSTRACT

A method and an apparatus for transmitting error-tolerant data is disclosed employing the ARQ technique, wherein the retransmission of erroneous data is performed up to the point where the remaining amount of errors is acceptable (for instance because the erorrs will not be perceived by the recipient of the information, which can be a person or a higher level protocol with additional error correction capabilities). The number of data blocks (RLC) detected as erroneous is employed to define a reliability measure (RM) and a request for retransmission of the erroneous data blocks is performed until a desired reliability threshold (RT) is reached. An additional threshold with a higher value than the first one can be employed to request for optional retransmission when the reliability measure (RM) is between the first and the second threshold. The retransmission will be performed only if further conditions such as channel availability are met.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a method for the transmission of datafrom a transmitter to a receiver, wherein the receiver performs a checkwhether received data is erroneous and wherein the transmitter performsa further data transmission according to said check.

BACKGROUND OF THE INVENTION

For the transmission of data from a transmitter to a receiver, it iscustomary to describe both the transmitter and the receiver as ahierarchy of protocol layers. For example, a hierarchy of layers maycomprise, in addition to optional further layers, a physical layer, alink layer, a transport layer and an application layer. Each layerperforms specific services in the transmission procedure for the nexthigher layer while the processing within and below said layer is hiddenfor higher layers. In this way, design and description of thetransmitting entities and protocols can be simplified.

In most cases, the data for transmission is divided into a plurality ofdata packets, which are passed through the hierarchy of protocol layers.During this processing, check sums for error detection or packet headersmay be added to the packets or removed from them in the layers. Datapackets can also be segmented, padded, interleaved or concatenatedaccording to the requirements of the particular layers. Thecorresponding data packets generally have different names, such asprotocol data unit (PDU), service data unit (SDU), packet, frame, cell,segment etc., depending on the specific protocol or technology involved.In the present specification, the term data packet generically relatesto any of such data packets, a PDU denotes a data packet of the protocollayer under consideration while an SDU denotes a data packet passed tothe next higher layer in the protocol stack.

During transmission, errors may occur in the transmitted data, e.g., adata packet may be totally lost or bit errors can occur within a datapacket or data stream. Especially for transmission protocols on linkswith a high probability of data errors, like wireless links, methods areapplied in the state of the art to detect and correct such errors. Inforward error correction (FEC), redundant data is transmitted whichallows the correction of erroneous data by the receiver.

In ARQ (Automatic Repeat Request) protocols, erroneous data, i.e. datacomprising transmission errors or lost data, is detected by the receiverand retransmitted according to a corresponding request sent by thereceiver to the transmitter. Original packets and retransmissions can beidentical but they can also differ, e.g. the original data and theretransmission may be coded differently or they may supplement eachother like in retransmission schemes with incremental redundancy. It isalso possible, that a retransmission is detected as erroneous due toloss or bit errors and selected for a further retransmission. To allowan identification of erroneous data, the data is generally transmittedin data packets comprising sequence numbers and/or check sums. Withincreasing probability of transmission errors, the error handling of theprotocol determines the transmission efficiency to a significant extent.

As an example, the RLC (Radio Link Control) link layer according to 3GPPspecifications allows a high transmission efficiency by operating radiobearers in acknowledged mode ensuring data reliability with an ARQprotocol. This is especially suitable for applications, which do notrequire strict delay bounds for the data and can tolerate additionaldelays introduced by the retransmissions. A highly efficienttransmission configuration in this case allows a certain number oftransmission errors, which avoids overprotection of the information bymuch FEC or excessive transmission power.

In data communications, applications and protocols are gettingincreasingly important which are able to cope with a certain amount oferrors, e.g. by performing error correction, error detection, byapplying error concealment techniques or any combination of suchmethods. Error tolerant applications are for example customary forvideo, audio or speech transmission. However, present transportprotocols in the Internet, like TCP (Transport Control Protocol) or UDP(User Datagram Protocol) are not adapted to error-tolerant applications.TCP is suited especially for applications, which require error freetransmission without strict delay-bounds. UDP can discard erroneous datapackets but does not guarantee reliable data transmission and is usedfor example for streaming applications with delay requirements. For thetransmission of data to error-tolerant applications within the Internet,the UDP Lite protocol has been proposed as a further Internet Standard.The UDP Lite protocol does not automatically discard data packets, inwhich transmission errors are detected but can forward them to theapplication, which can in turn apply an error correction or concealmenton the application layer. However, no automatic repeat request protocolexists, which is suited for error tolerant applications. Therefore, thetransmission efficiency remains limited and the advantages oferror-tolerant applications and protocols can at most partly beexploited.

SUMMARY AND DESCRIPTION OF THE INVENTION

It is an object of the present invention to obviate the abovedisadvantages and provide a method for an effective data transmission ina protocol allowing transmission errors.

In the proposed method, a receiving protocol layer receives data from atransmitter via a transmission link and a reliability measure isdetermined for the received data. Preferably, the reliability measure isdetermined for a defined range of received data. If the data istransmitted in data packets, the range of received data can be a datapacket, one or more selected parts of a data packet or a group of datapackets, e.g. a predefined number of consecutive packets. A data packetcan be for example a protocol data unit, an SDU contained in parts ofone or more protocol data units or any higher layer protocol data unit,e.g. an ADU (Application Data Unit) contained in parts of one or moreprotocol data units.

The reliability measure indicates whether received data compriseserrors. It can indicate for example the occurrence of errors in a rangeof data, the probability of errors in the data or a fraction of errorsin the data. Reliability measures can be obtained either by the protocollayer performing the method or by another layer in the protocol stack,e.g. by the physical layer. Examples of suitable reliability measuresare a measured signal to interference ratio, information from thechannel decoder like path weights, information from checks for errordetection like a number of erroneous protocol data units per SDU or ADUor a number of erroneous data packets within a certain time interval.The reliability measure can also relate to individual bits or bit errorpercentages in the data. Any combination of such reliability measurescan be used.

In a subsequent comparison, the reliability measure is compared to areliability threshold relating to the level of acceptable errors in thedata. The reliability threshold can differ for different parts of thetransmitted data. At least for one part of the data, the level ofacceptable errors is higher than zero and the reliability threshold isbelow the value corresponding to error-free data. According to theresult of the comparison, a decision is performed whether a data packetis retransmitted. It is preferable, to select data for retransmission,which is detected in a check as erroneous. Alternatively, especially ifthe reliability measure indicates an error probability like a signal tointerference ratio, retransmissions can be performed without a checkwhich packets are erroneous. In the latter case, packets can be selectedfor retransmission in a defined sequence or statistically. If thereceived data is sufficiently reliable, i.e. if the reliabilitythreshold is at least reached, retransmissions are either not performedor they are only performed according to further conditions.

The described method allows an effective transmission of data sufferingtransmission errors, especially for a protocol transporting data of anerror-tolerant application or an error-tolerant higher protocol layer.It is suited to all types of error resilient applications, especiallystreaming. The use of transmission resources, especially networkresources and radio resources, can be significantly reduced. Localresources in the transmitter or receiver can also be saved, e.g. memoryor battery consumption. The method can enhance the quality of serviceboth for the considered transmission or user as well as for furtherusers of a communication system who can use the additional resources.Transmission delays and—in case of in-sequence delivery ofpackets—bursts of released data are reduced, since transmitted data canbe passed to the next entity or layer when it is has reached asufficient quality. The method is applicable on different protocollayers of a transmission system, e.g. on a link layer or a transportlayer, and in different types of communication systems, for example in aGSM or UMTS or CDMA 2000 communication system or in a WLAN system. Themethod can also be used in hybrid ARQ transmission schemes, in whichredundant data sent with the original data or with the retransmissionallows a correction of errors from the redundancies and theretransmitted data.

In an advantageous embodiment, the further data transmissions areperformed for data, which is detected in a check as erroneous. In thisway, existing ARQ protocols can be easily adapted to the proposedmethod.

Generally, it is possible that the reliability measure or the result ofthe comparison is transmitted between receiver and transmitter andeither of the entities may perform the decision whether a retransmissionis executed. In a preferred embodiment, the receiver requests theretransmissions according to the comparison. In this way, the signalingbetween transmitter and receiver is minimized.

Typically, a data packet comprises a header part and part for thepayload data. Errors in the payload data part can often be corrected,concealed or ignored while errors in a protocol header may cause amalfunctioning of the protocol. Also within the payload, different partsof a packet may have different relevance for the quality level, like forexample in customary video and audio codecs. Parts of the payload canalso differ in relevance for other layers of the protocol stack, e.g. ifthe header of one protocol is a payload in an underlying protocol layer.If it is possible to detect in which part of the data an error occurs,for example by attributing a check sum to an individual part, areliability measure can be determined for the individual part andcompared to a corresponding threshold. This gives the advantageousopportunity to handle parts of the data with different relevancedifferently and select only valuable data packets for retransmissionwhile skipping retransmissions of other corrupted parts. Data with anerror in a sensitive part of said data or of a higher protocol layer canbe requested for retransmission with high persistence while higher errorrates can be allowed in less sensitive parts of the received data.

One or more further conditions can determine whether a retransmission ofa data packet is performed. The further condition can be checked in afurther comparison, in which the same or a different reliability measureis compared to a further threshold. The further condition can, e.g.,check whether a retransmission increases the quality of service for theapplication from a first to a second predefined level. In order toensure a certain quality of service, a further condition can also be acomparison of resources required for retransmission to a specificthreshold, e.g. for the amount of radio resources required for aretransmission. Retransmissions may, e.g. by delaying other data, affectthe quality of service both for the transmission under consideration andfor other users in a communication system. Further conditionsdetermining the quality of service may also be considered, e.g. athreshold for the time a data packet is already stored for transmissionor a delay budget remaining for transmission. Also the use of localresources in the transmitter or receiver, like memory or batteryconsumption, may be checked in the further condition. Any combination ofthe above conditions is possible. This allows for example to chose thereliability level according to available resources.

If a second reliability threshold is defined, i.e. if two or morereliability thresholds exist, it is possible to perform a decision tocontinue retransmissions until a selected one of the at least twothresholds is achieved. In this way, different levels of transmissionquality can be selected. The decision can be based on any furthercondition as described in the preceding paragraph.

A transmitter for an ARQ protocol in the state of the art generallyreceives information about lost data packets, while this is not the casefor the present method after the reliability threshold is reached.Optionally, the receiver sends therefore a reliability information tothe transmitter, for example included in a retransmission requestmessage or in a separate message. The reliability information indicatesan error level, i.e. the transmission quality, and can be thereliability measure or information calculated from reliability measures.In this way, the transmitter can adjust operating parameters accordingto the reliability information.

The information whether a retransmission is advantageous for one orseveral users of a communication system is in many cases available atthe transmitter. It can for example be derived from the content fortransmission or operational parameters of the communication system. Toallow the decision by the transmitter whether a retransmission isperformed, an optional retransmission request can be defined in additionto mandatory retransmission requests. Optional and mandatoryretransmission requests can be different types messages or they can bedistinguished by an option field in a message. An optionalretransmission request is sent if the reliability measure is at leastequal to the reliability threshold, i.e. a selected one of thethresholds in case that more than one threshold is defined. For anoptional retransmission request, a value of importance for all orspecific retransmissions can be indicated by the receiver with therequest or it may be determined from information present at thetransmitter. Compared to a mandatory retransmission request, thetransmitter performs at least one further decision, whether aretransmission is performed in reply to the optional retransmissionrequest. The result of the decision as well as the value of importancefor retransmissions can be determined for example according to areliability measure and/or a reliability threshold, the resourcesrequired for retransmission, conditions determining the quality ofservice like a delay budget remaining for transmission or anycombination of these.

In a further advantageous embodiment, the transmitter can send areliability requirement to the receiver. The reliability requirementrelates to the significance of data packets, e.g. a PDU, SDU or ADU,parts or groups of them and can be used to select the reliabilitythreshold. The reliability requirement can be included in a header fieldof a protocol data unit or it may be separate message. In this way, theflexibility of the method is improved compared to pre-configuredthresholds. For example, the thresholds may be adapted according to thetotal loading of the communication system by the users.

If partly erroneous data is transmitted, the further problem occurs thathigher protocol layers and the application in the receiver are obliviousof the reliability of the received data. To improve the data processing,it is advantageous to provide the reliability measure to a higherprotocol layer or application and adapt the processing of said layer orapplication according to the reliability measure. The application orhigher protocol layer can use the information in improved errorconcealment methods, e.g. by applying different data handling or errorconcealment algorithms according to the data reliability. For example,an application can perform a decision according to the reliabilityinformation whether error correction or error concealment need to beperformed or whether errors can be ignored.

A receiver according to the invention receives data sent by atransmitter and forwards it for further processing to a further layer ina protocol stack or to an application. The receiver has a receiving unitfor the data, generally data packets. The receiving unit decodes thereceived data and forwards it to a processing system, which performs acheck whether data is erroneous. For example, the receiver can detectmissing data packets discarded in the receiving unit due to an errorfrom a missing sequence number. Bit errors in a data packet can bedetected from a cyclic redundancy check (CRC). A transmission unit inthe receiver, generally integrated with the receiving unit, is adaptedto send a request to the transmitter for a further transmission of dataaccording to the check, especially of the data being detected aserroneous.

The processing system comprises a unit for determining a reliabilitymeasure for the received data, e.g. from one of the above checks. Areliability measure can also be obtained from the receiving unit, e.g. asignal-to-interference ratio. Furthermore, the processing systemcomprises a unit for a comparison of the reliability measure to areliability threshold. The processing system is adapted to initiate therequest for the retransmission of the data according to the result ofthe comparison, e.g. of data packets detected to be erroneous. For thispurpose, the processing system can perform a decision whether aretransmission is requested or whether the request is mandatory oroptional. The units in the processing system can be implemented assoftware code and they can perform any embodiments of the above method.

If the above method is implemented exclusively in the receiver, atransmitter as known in the state of the art can be used in the method.A corresponding transmitter has a transmission unit for sending data toa receiver and a receiving unit for receiving requests from the receiverfor a further transmission of previously sent data. Typically, bothunits are part of a transceiver. A processing system stores the sentdata in a memory, retrieves stored data according to the requests andinitiates a retransmission of the retrieved data by the transmissionunit.

It is often advantageous to perform all or some steps of the method inthe transmitter. In this case, the transmitter comprises, in addition tothe described units, a processing-system with a unit for determining areliability measure for the received data, for example by measurementsor by extracting the information from a message sent by the receiver.The processing system comprises a unit for a comparison of thereliability measure to a reliability threshold and it is adapted toinitiate retransmissions of the indicated data packets according to theresult of the comparison. The units in the processing system may be forexample implemented as software code. They can perform any embodimentsof the above method.

If a transmitter receives an optional retransmission request, theretransmission decision can be based on the importance of aretransmission for a service. The importance can be indicated in therequest message or it can be determined by the transmitter, e.g. if aPDU contains a header of a higher protocol layer. Furthermore, resourcespresently available, the load and requirements of other services,transmitter operating conditions like the queue fill state for radiolinks, the data rate currently available or the time data packets havealready spent in transmitter memories, buffers and queues or anycombination of these conditions can be considered.

A program unit according to the invention controls the transmission ofdata from a transmitter to a receiver. The program unit implements aprotocol, in which the receiver performs a check whether received datais erroneous and wherein the transmitter performs a further transmissionof data according to the check. The program unit comprises software codefor performing the steps of obtaining a reliability measure for thereceived data, performing a comparison of the reliability measure to areliability threshold, and initiating the further data transmissionsaccording to the result of the comparison. The program unit is forexample stored on a data carrier or loadable into a transmitter orreceiver, e.g. as a sequence of signals. It may be part of a softwarepacket comprising further software components, e.g. a processing system.The program unit can be used in any embodiments of the above method.

The foregoing and other objects, features and advantages of the presentinvention will become more apparent in the following detaileddescription of preferred embodiments as illustrated in the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a shows a data transmission over a connection including anunreliable link,

FIG. 1 b shows a receiver for the transmission,

FIG. 2 shows a transmission of data packets from a transmitter to areceiver according to the invention,

FIG. 3 shows the forwarding of reliability information between differentprotocol entities

FIG. 4 a shows an advantageous format for a reliability information

FIG. 4 b shows an example of a data packet comprising the reliabilityinformation of FIG. 4 a.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

In FIG. 1 a, a data transmission is shown from a transmitter ST to areceiver SR with the corresponding protocol layers. The connection isperformed over different networks FN1, FN2 and includes an unreliablelink WL between an optional intermediate receiver SR′ and an optionalintermediate transmitter ST′. In FIG. 1 a, different entities are thetransmitters and receivers for different protocol layers on the wirelesslink WL, i.e. for the three lower layers the intermediate receiver SR′and intermediate transmitter ST′ are the entities involved while higherlayers are only processed in transmitter ST and receiver SR. NetworksFN1, FN2 are optional entities and it is customary, e.g. for a mobilephone, that all protocol layers are integrated in a single device SR″connected to the intermediate transmitter ST′ over a wireless link WL′.However, a Bluetooth network, infrared links or another ad hoc networkFN2 may connect different user devices, e.g. laptop, mobile phone orpersonal digital assistant (PDA).

Every transmitter ST, ST′ receives service data units (SDU) from ahigher protocol layer or from an interworking function and transmitsthem in one or more protocol data units (PDU) to the correspondingprotocol layer of the receiver SR, SR′, SR″. In the example, theprotocol stack comprises a physical layer L1, a link layer L2, aconvergence protocol CP for the wireless link WL, the Internet ProtocolIP, the User Datagram Protocol UDP and the Real Time Protocol RTP, whichreceives the data from the application at the transmitter ST andforwards it to the application at the receiver SR, SR″.

FIG. 1 b shows a receiver SR″ for the transmitted data. A transceiverunit TRU allows the encoding of data for transmission and the sending ofdata to other devices as well as for the reception and decoding of data.Generally, data DP is sent in data packets. The protocol stack isimplemented in a processing system PRU providing the required processingand storing functionality for executing the data processing. The data isforwarded between the transceiver unit TRU and the lowest layer L1 inthe protocol stack. Corresponding functionality is also implemented inall other entities depicted in FIG. 1 a, i.e. all receivers SR, SR′, SR″and transmitters ST, ST′. In addition, the final receiver SR, SR″ has aninput and output unit IOU, e.g. with a keyboard, loudspeakers and adisplay, for the presentation of data to a user and for receiving usercommands. Often, an input and output unit IOU has also a processing andstoring unit with a memory or hard disk. The protocol stack has anapplication layer AP for exchanging. data with the input and output unitIOU.

At least one protocol layer in one of the receivers SR, SR′, SR″ checksthe received data packets for errors or missing packets and requestsretransmissions from the corresponding protocol layer in the transmitterST, ST′. This protocol is denoted ARQ protocol although there may beseveral layers in the protocol stack with an ARQ mechanism. According tothe requests, the transmitter retransmits previously transmitted datapackets.

The proposed ARQ protocol is adapted to the requirements oferror-tolerant applications. For example, a client application executedin receiver SR can request to receive data with a defined level ofreliability. The requested level of reliability is for example theminimum level of correctly received data required to process the data orit may correspond to a required output quality of the application. Datais transmitted over links in the networks FN1, FN2 including wirelesslink WL, which may all introduce errors into the transmitted data, e.g.if packets are dropped due to congestion in a network FN1, FN2 or due toa transmission error on the wireless link WL.

To recover from the errors, the ARQ protocol applies the proposedmethod. If several ARQ protocols are present, it is possible thatseveral protocol layers perform the proposed method, e.g. both thetransport layer and the link layer. The level of reliability requestedby the application is mapped to a reliability threshold at the protocollayer applying the proposed method. The reliability thresholdcorresponds to the acceptable level of errors and is below the valuecorresponding to error-free data, e.g. below 100% if the reliabilitythreshold represents the required fraction of correct data. If severalprotocol layers perform the method, the thresholds may differ for thelayers.

In contrast to the state-of-the art, the proposed protocol ARQ does notrecover from all transmission errors, i.e. retransmission requests arenot sent until all data is transmitted successfully. Rather, requests ofretransmissions for erroneous data are only sent until the received datahas reached the defined reliability threshold. Even if data packets arestill erroneous and there is enough time for retransmissions, no furtherretransmissions are performed after the reliability threshold isreached.

Streaming technology allows a nearly instantaneous access for the usersto pre-stored content without the necessity to transfer a complete filebefore presentation. Streaming applications, e.g. for video or audiofiles, can often perform a concealment of bit errors to a certainextent. On the application layer, forward error correction can beapplied alternatively or in addition to ARQ methods, i.e. theapplication layer can correct bit errors from redundant information.Furthermore, an application may tolerate bit errors, like many voicecodecs for speech transmission, e.g. the Adaptive Multirate Codec (AMR).

However, streaming applications have transfer delay requirements on thecommunication path, which need to be fulfilled in order to achieve arequired quality. Data packets arriving after the delay limit aredropped because the processing of the corresponding information must befinished before the presentation time to the user. As retransmissionsfor correcting errors introduce delays, ARQ protocols can only beapplied if the delay requirements are not too tight. If both delay andquality requirements exist, a suitable level of both errors and delay isrequired.

The proposed method is especially advantageous for a streaming serviceover a radio bearer of a communications system using an ARQ protocol. Ifthe streaming is performed from a server connected to the communicationsystem, the intermediate transmitter ST′ is for example a radio basestation (RBS) or a radio network controller (RNC), depending on the ARQlayer in the protocol stack, while the receiver SR″ can be a userequipment. It is, however, also possible to perform a streaming in theup-link with the user equipment as transmitter and the RBS or RNC asreceiver.

The processing of data packets for transmission is shown in more detailin FIG. 2, depicting only selected layers of the protocol stack forsimplicity. A video stream can comprise different types of frames,including information being part of an image or information aboutchanges between consecutive images. One example is an I-frame of a videostream, which can be larger than an IP (Internet Protocol) packet. Ifthe transmitter ST2 forwards the I-frame from the application layer ofthe protocol stack to the IP layer, it is therefore divided into severalIP packets, each having a header part H and a payload part P. When theIP packets are processed for further transmission by the link layer L2,an IP packet does generally not fit into one data block RLC, which isthe link layer PDU of a UMTS communication system. Therefore, a furthersegmentation is performed on the link layer L2.

The packets are then forwarded to the physical layer L1 for transmissionover the radio connection RC to the receiver SR2. The receiver SR2performs a reverse processing for all layers to assemble applicationI-frames from the RLC packets by removing header parts H andconcatenating the payload parts P. The RLC packets comprise also acontrol information part, which allows to perform a check whether biterrors occurred on the radio connection RC.

In the example, the application can tolerate up to 20% bit errors, i.e.it needs 80% correct bits in the payload to process the information. Ina resource-efficient transmission the ARQ process can be stopped if thisthreshold is passed. Existing ARQ protocols retransmit every data blockuntil a delay budget for the data block is expired or a maximum numberof retransmissions has been reached. In the proposed method, resourceutilization is improved by stopping the retransmission process for data,which is sufficiently error-free. The required level is preferablydetermined by the application because the error level, which can betolerated, may vary considerably for different types of applications,like audio or video, or for different processing methods, e.g. if errorconcealment can be performed or if redundant information allows errorcorrection. Resources, which are not needed for retransmission, can beused to transmit new data for the same user or they may be attributed toother users.

A reliability measure RM is defined to check whether the received datahas a sufficiently low error level. The reliability measure RM ispreferably selected to indicate whether an erroneous data segment canstill be processed. For example, a fatal error in a sensitive part canrequire that a packet needs to be totally dropped, e.g. if a bit errordestroys the packet sequence number. Errors in less sensitiveinformation can still allow a processing. If an error can be fatal, itis sufficient if the reliability measure indicates whether a data unitis error free or comprises an error. The reliability measure for dataunits, which can be processed in case of errors, preferably indicatesthe error level. The reliability measure for every data unit can bedetermined for example from decoding information provided by thephysical layer or from error-detecting codes of the protocol. Thereliability measure is then compiled for all data units in a datasegment under consideration and the aggregated reliability measure forthe segment is compared with a reliability threshold. Retransmissionsare requested until the threshold is reached.

Information about packets of higher layers can be used for thedefinition of a suitable reliability measure or the selection of anappropriate threshold. For example the IP headers must be correct toallow the processing of IP packets. Otherwise, the IP packet is dropped.Therefore, a further check preferably determines whether the informationreassembled from the data blocks RLC results in a valid IP packet withintact header and a correct packet size. The IP header comprises a CRCfield as well as a field indicating the packet size. The CRC can be usedto check whether the header is intact. A check of the packet size isadvantageous if concatenation is used on a lower layer, i.e. if a PDU ofthe lower layer can contain parts of two IP packets. In this case, theframing of the IP packet is ambiguous if the boundary between the IPpackets cannot be determined. If a complete lower layer data packet ismissing, the length information of the IP packet can be used to pad themissing payload part.

In the simple embodiment of FIG. 2, the fraction of error-free datablocks RLC is counted for each IP packet on the RLC protocol layer. Thereliability measure RM is therefore the fraction of error free datablocks RLC in an IP packet. If at least 80% of the data blocks RLC in anIP packet are error free, retransmission requests for data blocks RLC inthis IP packet are stopped. Preferably, data blocks RLC comprising partsof the IP header H are treated differently because the whole IP packetis dropped in case of an erroneous header. The corresponding data blocksRLC are preferably retransmitted until they are correctly received oruntil their delay budget expires.

Alternatively, the reliability measure RM can be determined on bitlevel, e.g. as a percentage of bit errors in a data packet or bit errorpositions can be indicated. Detailed information about errors isespecially advantageous if the reliability measure is evaluated withinthe entity in which it is determined and the transmission overhead fordetailed information is acceptable, e.g. due to transmission on aninternal data bus.

Defining more than one level of reliability can further enhance themethod. For example, the quality of service may be improved if thereceived data is of reliability level B, which is higher than a minimumlevel A required for processing. In this case, the transmitter or thereceiver can continue to initiate retransmissions for error recoverybeyond reliability level A up to reliability level B. The decisionwhether to perform retransmissions until achieving either reliabilitylevel can be based on a single or several parameters from a groupcomprising service requirements, e.g. a remaining delay budget,prioritization, e.g. selected services or users, radio resourceavailability and costs.

In some protocols, transmitter and receiver windows are used to trackerroneous or unacknowledged data packets. If the receiver receives adata packet outside the receiver window, the packet is discarded whilethe transmitter performs only retransmissions of packets within thetransmitter window. Else malfunctions of the protocol may occur,especially if cyclic numbering schemes are used for the data packets.

The above method can also be used together with transmitter and receiverwindows. Especially, it is possible to advance the receiver window ifthe required reliability for the data packets is achieved. Toaccommodate optional retransmissions, a further section of the receiverwindow may be defined below the receiver window. The further section canbe moved if no retransmissions are received within a certain time, e.g.within a round trip time of the protocol. The transmitter window can bemoved after a decision to send no further retransmissions for selecteddata. A message from the transmitter to the receiver initiates acorresponding move the receiver window, e.g. according to the procedure“Move Receiver Window” as defined in the 3GPP specifications.

In the proposed method, the selection of the reliability thresholdensures the provision of data with a sufficient quality level to theapplication while allowing a highly effective transmission. For anappropriate definition of the threshold, it is necessary to provide thereliability requirements of the application or a higher protocol layerto the ARQ protocol. Both for the source and the means of providing thereliability requirements, a plurality of options exists. Informationdetermining the reliability thresholds can for example be pre-configuredor it is provided by the application, the user or a further protocol.

Information defining the reliability requirements can for example besignaled in a further protocol like a reservation protocol, e.g. in anextension to the RSVP (Resource Reservation Protocol). Reliabilityrequirements can also be provided or negotiated during the setup of aconnection. For a transport protocol, reliability requirements can beoptions negotiated at the socket interface. For a radio link protocolthey can be included in a radio bearer establishment request, eitherfrom the client terminal or from the network. A pre-configuredreliability requirement can be stored as a profile. Reliabilityrequirements can also be determined from the transmitted data, e.g.according to the type of transported media which can be determined fromthe protocol headers. For example, if the UDP Lite protocol transportsthe RTP (real-time protocol) with a specific RTP format, i.e. mediatype, a certain reliability requirement can be pre-configured for thiscombination. Reliability requirements can also be signaled in thetransmitted data, e.g. as an option field in packet headers.Combinations of these options are possible, especially if severalthresholds are used.

In a further improvement of the method, reliability information isprovided to the application or a further protocol layer. For thispurpose, functionality is required to pass reliability information in aneffective way along with the information that is transmitted.Reliability information is in particular available at the receiving sideof the ARQ protocol although any reliability information gathered alongthe path through the network can be used. The reliability informationcan be used for example in error concealment or correction procedures.Although the use and forwarding of reliability information is describedhere with respect to a method for performing retransmissions, it shouldbe noted that the use and forwarding of reliability information asdescribed is a general principle which can also be used for a protocolwithout retransmissions or for a protocol performing retransmissionsdifferently from the proposed method.

Within a single protocol stack, forwarding of reliability informationcan be performed by well-known procedures, e.g. by primitives sentbetween the layers or by using shared memories. However, oftenreliability information has to be forwarded to a different protocolentity as depicted in FIG. 3. Transmitters ST3, ST3′ comprise protocollayers as described with respect to FIG. 1, except that a generictransport protocol TP and an application layer AP are indicated in theprotocol stack. The receiver consists of a mobile terminal MT connectedover a standard interface INT to a terminal equipment TE. Mobileterminal MT and terminal equipment TE may be implemented in the samehardware e.g. in a multimedia mobile phone, or in separate hardwareunits, e.g. in a laptop connected to a mobile phone over a cable or aBluetooth-link. On the wireless link WL, packet losses may occur on thelink layer L2, e.g. due to a transmission without acknowledgements ordue to packets dropped after excessive delays in an acknowledgedtransmission scheme. The protocol AQP performing retransmissionsaccording to the proposed method is in this case the transport layer TPin the terminal equipment while the reliability information is availableon the link layer L2 in the mobile terminal MT.

For the forwarding of reliability information INF between logically orphysically separate protocol entities, several alternatives exist. Asthe forwarding within a protocol stack is straightforward, it ispossible that another layer than the protocol AQP performingretransmissions receives the forwarded reliability information INF inthe receiving entity. For example, in FIG. 3 the layer IP in theterminal equipment TE receives the reliability information INF andforwards it to the protocol AQP.

An example for an advantageous format of reliability information RI isshown in FIG. 4 a. A field SSI specifies the segment size, i.e. thegranularity, for which reliability information is available. A field NOSindicates the number of segments to which the reliability informationrelates. A bitmap BMP represents the reliability of each segment,wherein one or more bits can relate to each segment. If a protocolallows segments of various lengths, a list indicating the size andreliability of each segment is an advantageous alternative to theembodiment shown. The granularity of reliability information can vary.Reliability information for every bit can be obtained from the channeldecoder on the physical layer but results in a large amount ofinformation. Information for layer 2 protocol data units, e.g. per RLCprotocol data unit in GPRS (General Packet Radio Service) or UMTSsystems, is an advantageous option and can be obtained from the CRCcheck at the link layer receiver. In both cases, an application canidentify error probabilities for different parts of the received data.

The reliability information can be passed to the application as headerfield of a higher layer protocol data unit. FIG. 4 b depicts the use ofthe general format as defined with respect to FIG. 4 a in an IP packet.The IP packet comprises the headers of several higher protocol layers aswell as application data and is sent from a sending protocol entity SPto a receiving entity RP. For this purpose, the IP packet is dividedinto a plurality of segments RLC corresponding to link layer protocoldata units and reassembled from them at the receiving entity RP. Thereliability information is indicated in an optional field of the IPheader, which is amended during assembly. In this case, the field SSI′corresponds to the size of the link layer PDU, the field NOS′ to thenumber of PDUs in an IP packet and the field BMP′ represents thereliability information for each PDU as entry in a bitmap. Theapplication at the receiver extracts the optional field. Animplementation of this alternative requires an extension of IP socketfeatures to allow the amendment of the reliability information.Advantageously, this alternative can be used together with theencryption of IPsec (secure Internet Protocol), because the IP header isnot encrypted and can therefore be amended by lower protocol layers.

Alternatively, reliability information can be appended to theapplication protocol data unit ADU. Due to the encryption of IPsec, thisalternative is not suitable for IPsec. Applications, which are notadapted to the additional information, can misinterpret the receiveddata. Therefore, the sender preferably triggers the appending ofreliability information to ADUs. One option for a UDP flow is an initialUDP message from the sender to the receiver on a specific port number,the message indicating the flow identity. The receiver monitors all UDPpackets and identifies the initial UDP message by the port number. Thereceiver then adds reliability information to UDP packets in the flowwith the indicated identity. If the application data is transmitted inADUs having a header, the information can be a header field of the ADUs,e.g. in the format depicted in FIG. 4 a. Alternatively it is included inthe payload.

In a further alternative, the receiving protocol entity can generate amessage to the receiving terminal. The message comprises the reliabilityinformation for a data flow and can be associated with the data flow bybeing sent to a specific port number. The application can synchronizethe data flow and the reliability information, e.g. if the RTP header isincluded in the message. This alternative is advantageous because indoes not require modifications of the socket interface of the receivingterminal.

The above embodiments admirably achieve the objects of the invention.However, it will be appreciated that departures can be made by thoseskilled in the art without departing from the scope of the invention,which is limited only by the claims.

1. A method for the transmission of data from a transmitter to areceiver, wherein a first protocol in the receiver performs a checkwhether received data is erroneous and wherein the transmitter performsa further data transmission according to said check, and wherein thefirst protocol processes the received data and passes a service dataunit to the next higher protocol layer, said method comprising the stepsof: determining a reliability measure for the received data; aggregatingthe reliability measure for at least a part of the service data unit;performing a comparison of the aggregated reliability measure to areliability threshold; and, performing retransmission of said receiveddata, which is detected as erroneous, according to the result of saidcomparison.
 2. The method according to claim 1, wherein the receiverrequests the further data transmissions according to the comparison. 3.The method according to claim 1, wherein the reliability measure isdetermined for a selected part of the received data.
 4. The methodaccording to claim 1, wherein at least a further condition determineswhether the further data transmission is performed.
 5. The methodaccording to claim 4, wherein at least one second reliability thresholdis defined and wherein a decision is performed to continue further datatransmissions until a selected one of the reliability thresholds isachieved.
 6. The method according to claim 1, wherein the receiver sendsreliability information indicating an error level of the received datato the transmitter.
 7. The method according to claim 2, wherein anoptional retransmission request is defined in the first protocol, thereceiver sends the optional retransmission request if the reliabilitymeasure is at least equal to said reliability threshold, and wherein thetransmitter performs a decision as to whether a further datatransmission is performed in reply to the optional retransmissionrequest.
 8. The method according to claim 1, wherein the transmittersends a reliability requirement to the receiver and the receiver selectsthe reliability threshold according to the reliability requirement. 9.The method according to claim 1, wherein the reliability measure isprovided to a higher protocol layer or an application and the processingof the higher protocol layer or the application is adapted according tothe reliability measure.
 10. A receiver for data sent by a transmitter,comprising: a processing system; a receiving unit for receiving the dataand for forwarding said data to said processing system, wherein theprocessing system is adapted to perform a check using a first protocolwhether received data is erroneous and the first protocol processes thereceived data and passes a service data unit to a next higher protocollayer; and, a transmission unit adapted to send a request to thetransmitter for retransmission of said data according to said check,wherein the processing system comprises a unit for determining areliability measure for the received data and for aggregating thereliability measure for at least a part of the service data unit, theprocessing system further comprises a unit for a comparison of theaggregated reliability measure to a reliability threshold, and theprocessing system is adapted to initiate the request for the furtherdata transmission according to the result of the comparison for datawhich is detected as erroneous.
 11. A transmitter, comprising: atransmission unit for sending data to a receiver in which a firstprotocol processes the data and passes a service data unit to a nexthigher protocol layer; a receiving unit for receiving requests from thereceiver for a retransmission of said data; and, a processing system forstoring the sent data and for retrieving the stored data according tothe requests and initiating a further data transmission by thetransmission unit, wherein the processing system comprises a unit fordetermining a reliability measure for the data received by the receiverand for aggregating the reliability measure for at least a part of theservice data unit, the processing system further comprising a unit for acomparison of the aggregated reliability measure to a reliabilitythreshold, and wherein the processing system is adapted to initiate thefurther data transmission according to the result of the comparison.